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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document defines the Radio Network Layer user plane protocol being used over the lu interface. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[ 1 ] 3GPP TS 25 .40 1 : "UTRAN Overall Description" . 

[2] 3GPP TS 25.410: "UTRAN lu interface: General Aspects and Principles". 

[3] 3GPP TS 25.413: "UTRAN lu interface RANAP Signalling". 

[4] 3GPP TS 25.414: "UTRAN lu Interface Data Transport and Transport SignalHng". 

[5] 3GPP TS 23.1 10: "UMTS Access Stratum Services and Functions". 

[6] 3GPP TS 23.221: "Architectural requirements". 

[7] ITU-T Recommendation 1.363.2 (1 1/2000): "B-ISDN ATM Adaptation Layer specification: Type 

2AAL". 

[8] ITU-T Recommendation 1.366.1 (6/98): "Segmentation and reassembly service specific 

convergence sublayer for the AAL type 2". 

[9] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[10] 3GPP TS 25.321: "Medium Access Control (MAC) protocol specification". 

[11] 3GPP TS 25.322: "Radio Link Control (RLC) protocol specification". 

[12] 3GPP TS 26.102: "Mandatory speech codec; AMR speech codec; Interface to lu and Uu". 

[13] 3GPP TS 23.153: "Out of Band Transcoder Control; Stage 2". 

[14] IETF RFC 1889: "RTP: A Transport Protocol for Real Time Applications" . 

[15] IETF RFC 1890: "RTP Profile for Audio and Video Conferences with Minimal Control". 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

lu Timing Interval (ITI): lu Timing Interval is the minimum time interval between sent lu UP PDUs for a specific 
RAB. The ITI can be calculated for conversational and streaming traffic classes by the following formula: 

_ MaxSDUsize 
MaxBitrate 

Inter PDU Transmission Interval (IPTI): inter PDU Transmission Interval is the actual interval at which lu UP PDUs 
can be sent at a certain time for a specific RAB subflow combination. The IPTI of a RAB subflow combination is 
calculated based on the RAB subflow combination size and the RAB subflow combination bitrate by dividing the RAB 
subflow combination size with the RAB subflow combination bitrate. 

RFC _size „ 

IPTI „ = — , s=\,...,n, n = number of subflowcombinations 

^ RFC _ Bitrate g 



NOTE: If RFC_Bitrate is not defined then IPTI=ITI. If RFC_size is not defined then RFC_size=MaxSDUsize. 

Non Access Stratum (NAS) Data Streams: non Access Stratum Data Streams is a generic term to identify these data 
streams exchanged at the Dedicated Service Access Points between the Non Access Stratum and the Access Stratum. 

RAB sub-flows: RAB as defined in TR 21.905 [9] is realised by UTRAN through one to several sub-flows. These sub- 
flows correspond to the NAS service data streams that have QoS characteristics that differ in a predefined manner 
within a RAB e.g. different reliability classes. 

RAB sub-flows characteristics: 

1) the sub-flows of a RAB are established and released together at the RAB establishment and release, respectively; 

2) the sub-flows of a RAB are submitted and delivered together at the RAB SAP; 

3) the sub-flows of a RAB are carried over the same lu transmission connection; 

4) the sub-flows of a RAB are organised in a predefined manner at the RAB SAP and over the lu interface. The 
organisation is imposed by the NAS as part of its co-ordination responsibility. 

RAB sub-flows numbering (applies to support mode for predefined SDU size only): 

1) RAB sub-flows are numbered from 1 to N (N is the number of sub-flows); 

2) RAB sub-flow number 1 corresponds to the highest reliability class and the RAB sub-flow number N 
corresponds to the lowest reliability class; 

3) RAB sub-flows order inside the lu frame is predefined so that RAB sub-flow number one comes first and the 
RAB sub-flow number N comes last. 

RAB sub-Flow Combination (RFC): RAB sub-flow combination is defined as an authorised combination of the RAB 
sub-flows variable attributes (e.g. SDU sizes) of currently valid RAB sub-flows that can be submitted simultaneously to 
the lu UP for transmission over lu interface. Each combination is given by the CN and cannot be altered by the SRNC. 

RAB sub-Flow Combination Indicator (RFCI): this indicator uniquely identifies a RAB sub-flow combination for 
the duration of the lu UP peer protocol instances i.e. it is valid until the termination of the call or until a new 
initialisation is performed. Usage of RFCI applies only to lu UP protocol operated in support mode for predefined SDU 
size. 
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Principles related to RFCI allocation and Initialisation procedure: 

1) RFCI value is present in every lu user frame; 

2) in the Initialisation procedure in lu UP, the size of every RAB sub-flow SDU for each RFCI is signalled. 

Syntactical error: field is defined to be syntactically incorrect in a frame if it contains at least one value defined as 
"reserved", or if its value part violates syntactic rules given in the specification of the value part. However it is not a 
syntactical error that a value specified as "spare" is being used. 

Semantical error: A frame is defined to have semantically incorrect contents if it contains information which, possibly 
dependant on the state of the receiver, is in contradiction to the resources of the receiver and/or to the procedural part. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AMR Adaptive Multi-Rate codec 

AS Access Stratum 

BER Bit Error Rate 

CN Core Network 

DS Data Service 

DTX Discontinuous Transmission 

DU Data Unit 

GF Galois Field 

IPTI Inter PDU Transmission Interval 

ITI lu Timing Interval 

NAS Non Access Stratum 

PCE Procedure Control Extension 

PDU Protocol Data Unit 

PME Procedure Control Bitmap Extension 

QoS Quality of Service 

RAB Radio Access Bearer 

RANAP Radio Access Network Application Part 

RFC RAB sub Flow Combination 

RFCI RFC Indicator 

RNL Radio Network Layer 

RTP Real-time Transport Protocol 

SAP Service Access Point 

SDU Service Data Unit 

SID Silence Insertion Descriptor 

SMpSDU Support Mode for predefined SDU size 

SRNC Serving RNC 

SRNS Serving RNS 

SSSAR Service Specific Segmentation and Reassembly 

TFCI Transport Format Combination Indicator 

TFI Transport Format Identification 

TFO Tandem Free Operation 

TNL Transport Network Layer 

TrFO Transcoder Free Operation 

TrM Transparent Mode 

UP User Plane 

UUI User to User Information 

3.3 Concepts 

lu UP mode of operation: 

One objective of the lu User Plane (UP) protocol is to remain independent of the CN domain (Circuit Switched or 
Packet Switched) and to have limited or no dependency with the Transport Network Layer. Meeting this objective 
provides the flexibility to evolve services regardless of the CN domain and to migrate services across CN domains. 
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The lu UP protocol is therefore defined with modes of operation that can be activated on a RAB basis rather than on a 
CN domain basis or (tele) service basis. The lu UP mode of operation determines if and which set of features shall be 
provided to meet e.g. the RAB QoS requirements. 

lu UP protocol PDU Type: 

The lu UP protocol PDU Types are defined for a given lu UP mode of operation. An lu UP PDU Type represents a 
defined structure of an lu UP protocol frame. For instance, a frame made of a certain Frame Header mask part and a 
Frame Payload part would be specified as a certain PDU type valid for a given lu UP mode of operation. 

Tandem Free Operation (TFO): 

Configuration of a Speech or Multimedia call for which Transcoders are physically present in the communication path 
but transcoding functions are disabled or partially disabled. The Transcoders may perform control and/or protocol 
conversion functions. 

Transcoder (TC): 

Physical device present in the network responsible for the transcoding of the speech data between two speech codecs or 
coding schemes (The Transcoder may also include other functions, i.e. Rate Adaptation in GSM). 

Transcoder Free Operation (TrFO): 

Configuration of a Speech or Multimedia call for which Transcoders are not present in the communication path. 

3.4 Specification Notations 

For the purposes of the present document, the following notations apply: 

Procedure When referring to a procedure in the specification the Procedure Name is written with the first 

letters in each word in upper case characters followed by the word "procedure", e.g. lu Rate 
Control procedure. 

Frame When referring to a control or data frame in the specification, the CONTROL/DATA FRAME 

NAME is written with all letters in upper case characters followed by the words "control/data 
frame", e.g. TIME ALIGNMENT control frame. 

IE When referring to an information element (IE) in the specification the Information Element Name 

is written with the first letters in each word in upper case characters and all letters in Italic font 
followed by the abbreviation "IE", e.g. Frame Number IE. 

Value of an IE When referring to the value of an information element (IE) in the specification the "Value" is 
written as it is specified in subclause 6.6.3 enclosed by quotation marks, e.g. "0" or "255". 

4 General 

4.1 General aspects 

The lu UP protocol is located in the User plane of the Radio Network layer over the lu interface: the lu UP protocol 
layer. 

The lu UP protocol is used to convey user data associated to Radio Access Bearers. 

One lu UP protocol instance is associated to one RAB and one RAB only. If several RABs are established towards one 
given UE, then these RABs make use of several lu UP protocol instances. 

In general, lu UP protocol instances exist at lu access point as defined in TS 25.410 [2] i.e. at CN and UTRAN. 
However, as described in TS 23.153 [13], if TrFO is possible and the lu UP protocol instances operate in support mode 
the lu UP protocol instance in CN may resume performing lu UP specific functions or vanish completely during stable 
call states. In this case the partner peer entity actually interacting with the UTRAN lu UP protocol instance (i.e. 
performing all lu UP specific functions except UP initialisation) may either be located within another UTRAN or within 
a CN node that is not the serving CN node of the UTRAN. 
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Whenever a RAB requires transfer of user data in the lu UP, an lu UP protocol instance exists at each lu interface 
access points. These lu UP protocol instances are established, relocated and release together with the associated RAB. 

Whether these peer protocol instances perform some RAB related function depends on the mode of operation of the lu 
UP as defined below. 

The following figure illustrates the logical placement of the lu UP protocol layer and the placement of the Data Streams 
sources outside of the Access Stratum. 
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Figure 1 : lu UP protocol layer occurrence in UTRAN overall architecture (User Plane View) 

4.2 Operational and Functional Aspects 

4.2.1 lu UP protocol modes of operation 

The lu UP protocol operates in mode according to the concept described in earlier subclause. 
Modes of operation of the protocol are defined; 

1) Transparent mode (TrM); 

2) Support mode for predefined SDU size (SMpSDU). 

Determination of the lu UP protocol instance mode of operation is a CN decision taken at RAB establishment based on 
e.g. the RAB characteristics. It is signalled in the Radio Network layer control plane at RAB assignment and relocation 
for each RAB. It is internally indicated to the lu UP protocol layer at user plane establishment. 

The choice of a mode is bound to the nature of the associated RAB and cannot be changed unless the RAB is changed. 

4.2.2 Transparent mode (TrIVI) 

The transparent mode is intended for those RABs that do not require any particular feature from the lu UP protocol 
other than transfer of user data. 

The following figure illustrates the transparent mode of operation of the lu UP protocol layer. 



£75/ 



3GPP TS 25.415 version 10.0.0 Release 10 



12 



ETSI TS 125 415 VI 0.0.0 (2011-04) 



UTRAN 











JU 


Ui 




o 






c 


o 






o 


o 


^Q. 1 


CO 




DC 





lu Interface 




lu UP layer In 
transparent mode 



TNL-SAP 



RNL-SAP 



CN 



Non Access 
Stratum 

Access Stratum 





lu UP layer in 
transparent mode 








Figure 2: lu UP protocol layer in transparent occurrence over lu interface 

In this mode, the lu UP protocol instance does not perform any lu UP protocol information exchange with its peer over 
the lu interface: no lu frame is sent. The lu UP protocol layer is crossed through by PDUs being exchanged between 
upper layers and transport network layer. 

For instance, the transfer of GTP-U PDUs could utilise the transparent mode of the lu UP protocol. 

This release of the specification defines transparent mode version 1, the same as in the release 99 specification. 

4.2.3 Support mode 

The support modes are intended for those RABs that do require particular features from the lu UP protocol in addition 
to transfer of user data. When operating in a support mode, the peer lu UP protocol instances exchange lu UP frames 
whereas in transparent mode, no lu UP frames are generated. 
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The following figure illustrates the functional model of the lu UP protocol layer in support mode of operation. 
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Figure 3: lu UP protocol layer in support mode occurrence over lu interface 

Some RABs requesting lu UP protocol support, constrain the lu UP protocol and possibly the radio interface protocols 
in specific ways. For instance, certain RABs can have variable predefined rates. 

The lu UP support mode is prepared to support variations. 

The only support mode defined here is the: 

Support mode for predefined SDU size (SMpSDU). 

For instance, the transfer of AMR speech PDUs would utilise the support mode for predefined SDU size of the lu UP 
protocol because it requires some Procedure Control functions and some NAS Data Streams specific functions while the 
sizes of the user data being transferred can vary in a predefined manner. 

This release of the specification defines the Support mode for predefined SDU sizes version 2. The Support mode for 
predefined SDU sizes version 1 (see release 99 of this specification) shall also be supported by a 3GPP implementation 
compliant to this release of the specification in order to be backward compatible with release 99. 



Transparent mode, version 1 



5.1 



General 



5.1 .1 Operation of the lu UP in Transparent mode 

The lu UP layer in transparent mode is present in the lu User plane for transferring data transparently over the lu 
interface. 

The two strata communicate through a Service Access Point for Non Access Stratum (NAS) Data Streams transfer. 
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5.1 .2 Interfaces of the lu UP protocol layer in Transparent mode 

Interfaces of the lu UP protocol layer in transparent mode are the transport network layer and the upper layers. The lu 
UP protocol layer in transparent mode is an empty layer through which NAS Data Streams PDUs are crossing between 
the Transport Network Layer and upper layers. 

The lu UP protocol layer in transparent mode is using services of the Transport layers in order to transfer the lu UP 
PDUs over the lu interface. 

5.2 lu UP Protocol layer Services in Transparent mode 

The following functions are needed to support this mode: 
Transfer of user data. 

5.3 Services Expected from the UP Data Transport layer 

The lu UP protocol layer in transparent mode expects the following services from the Transport Network Layer: 
Transfer of user data. 
Delivery of SDUs in sequence when requested by the RAB parameter Delivery Order IE (TS 25.413 [3]). 

5.4 Elements for lu UP communication in Transparent mode 
5.4.1 Frame Format for transparent mode 

The following shows the format of the PDU crossing the lu UP protocol layer in transparent mode. This frame is 
transferred transparently between the lu UP protocol upper layers and transport network layer (TNL-SAP). 



Oct1 




Octn 



Figure 4: Frame format for transparent mode 

This PDU has a variable length of n octets, whose maximum range depends on the type of user data (e.g. IP packet). No 
explicit length indication is visible at the lu UP protocol layer. 



Support mode for predefined SDU sizes, version 2 



6.1 



General 



6.1 .1 Operation of the lu UP in Support mode 

The lu UP protocol layer in Support mode is present for data streams that need frame handling in the UP. 
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The two strata communicate through a Service Access Point for Non Access Stratum (NAS) Data Streams transfer. 

6.1 .2 Interfaces of the lu UP protocol layer in Support mode 

As part of the Access Stratum responsibihty, the lu UP protocol layer in support mode provides the services and 
functions that are necessary to handle non access stratum data streams. The lu UP protocol layer in support mode is 
providing these services to the UP upper layers through a Dedicated Service Access Point used for Information Transfer 
as specified in TS 23.110 [5]. 

The lu UP protocol layer in support mode is using services of the Transport layers in order to transfer the lu UP PDUs 
over the lu interface. 

6.2 lu UP Protocol layer Services in Support mode 

Support mode for predefined SDU size Service 

The following functions are needed to support this mode: 
Transfer of user data; 
Initialisation; 
Rate control; 
Time alignment; 
Handling of error event; 
Frame quality classification. 

6.3 Services Expected from the UP Data Transport layer 

The lu UP protocol layer in Support Mode expects the following services from the Transport Network Layer: 
Transfer of user data. 
Delivery of SDUs in sequence when requested by the RAB parameter Delivery Order IE (TS 25.413 [3]). 
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6.4 

6.4.1 



Functions of the lu UP Protocol Layer in Support mode 
Functional model of the lu UP Protocol Layer in Support mode 
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Figure 5: Functional model of the lu UP protocol layer in Support mode 

The lu UP protocol layer in Support mode is made of three sets of functions: 

1) Frame Handler function; 

2) Procedure Control functions; 

3) Non Access Stratum Data Streams specific functions. 

6.4.2 Frame Handler function 

This function is responsible for framing and de-framing the different parts of an lu UP protocol frame. This function 
takes the different parts of the lu UP protocol frame and set the control part field to the correct values, including the 
handling of the frame number. It also ensures that the frame control part is semantically correct. This function is 
responsible for interacting with the Transport layers. This function is also responsible for the CRC check of the lu UP 
frame header. The lu UP frame with header CRC check error is discarded. 

6.4.3 Procedure Control functions 

This set of functions offers the control of a number of procedures handled at the lu UP protocol level. These functions 
are responsible for the procedure control part of the lu UP frames. 

Namely, these procedures are: 

Rate Control: is the procedure which controls over the lu UP the maximum rate that is allowed to be sent 
downlink among the rates that can be controlled. The set of rates is represented by RFCI indicators. The function 
controlling this procedure interacts with functions outside of the lu UP protocol layer. 

Initialisation: is the procedure which controls the exchange of initialisation information that is required for 
operation in support mode for predefined SDU size. Such information can contain the RFCI Set to be used until 
termination of the connection or until the next Initialisation procedure. This procedure is also used for 
negotiating the version of the lu UP Mode among the versions the CN requested for the related RAB. 
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Time Alignment: is the procedure that controls the timing of the downlink data to the RNC over lu. The 
function controlling this procedure interacts with functions outside of the lu UP protocol layer. 

Handling of Error Event: is the procedure that controls the information exchanged over the lu related to 
detection of a fault situation. The function controlling this procedure interacts with functions outside of the lu 
UP protocol layer. 

6.4.4 Non Access Stratum Data Streams specific function(s) 

These functions are responsible for a "limited manipulation" of the payload. These functions are responsible for the 
CRC check and calculation of the lu UP frame payload part. These functions are also responsible for the Frame Quality 
Classification handling as described below. 

These functions interact with the upper layers by exchanging lu data stream blocks of lu UP frame payload. These 
functions also handle the padding and depadding of the lu UP frame payloads when needed. 

These functions interact with the Procedure Control functions. 

These functions provide service access to the upper layers for the Procedure Control functions. 



6.4.4.1 



Frame Quality Classification function 



6.4.4.1.1 



General 



On the lu UP in Support Mode the frames are classified with the Frame Quality Classifier (FQC). This classifying is 
based on the radio frame classification and the setting of the RAB attribute Delivery of erroneous SDUIE. The RAB 
attribute Delivery of erroneous SDU IE tells if erroneous frames shall be delivered or not. 

Figure 6 shows the main input and output information for frame quality classification function on the lu UP. 
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Figure 6: Frame quality classification in lu UP 



6.4.4.1.2 



Handling of FQC information in uplink path 



6.4.4.1.2.1 



Handling of FQC information at RNC 



In SRNC on the sending side, the Support Mode Functions takes as input the radio frame quality information together 
with the frame. Based on this, the Frame Quality Classification (FQC) IE is set for the frame, a CRC is or is not added 
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(depending on PDU type) and the frame is sent to CN. The following steps shall be sequentially applied to derive the 
SRNC behaviour and the Frame Quality Classification (FQC) IE setting: 

a) If there is at least one subflow with the Delivery of erroneous SDU IE set to "No" and for at least one of those 
subflows the radio frame classification is "Bad" then the lu UP frame shall not be sent; 

b) Otherwise, if there is at least one subflow with the Delivery of erroneous SDU IE set to "Yes" and for at least 
one of those subflows the radio frame classification is "Bad" then the lu UP frame shall be sent with Frame 
Quality Classification (FQC) IE set to "frame bad due to radio"; 

c) Otherwise the lu UP frame shall be sent with Frame Quality Classification (FQC) IE set to "frame good". 

6.4.4.1 .2.2 Handling of FQC information at CN 

The Support Mode Functions in CN on the receiving side makes a CRC check of the frame payload, if CRC is present 
and passes the appropriate frame and the appropriate frame quality classification information through the RNL-SAP. 
The following steps shall be sequentially applied to derive the CN behaviour and the FQC field setting: 

a) If a CRC is available and the CRC check indicates that the lu UP frame payload part is corrupted and at least one 
subflow has the Delivery of erroneous SDU IE set to "No", then the lu UP frame shall be dropped; 

b) Otherwise, if a CRC is available and the CRC check indicates that the lu UP frame payload part is corrupted and 
at least one subflow has the Delivery of erroneous SDU IE set to "Yes", then the lu UP frame shall be forwarded 
with the FQC set to "frame bad"; 

c) Otherwise the lu UP frame shall be forwarded with the FQC as set by UTRAN. 

6.4.4.1 .3 Handling of FQC information in downlink path 

The Support Mode Functions in CN on the sending side adds a CRC, if necessary to the frame payload and passes it 
together with the FQC. If the payload stems from a transcoding unit of the NAS within the CN the FQC is always set to 
"frame good". Otherwise it may be set by a partner peer entity residing in another RNC. 

The Support Mode Functions in SRNC then makes a CRC-check, if the CRC is present. Based on the CRC check, a 
decision is made whether to deliver the frame or not based on the following sequential steps: 

a) If a CRC is available and the CRC check indicates that the lu UP frame payload part is corrupted then the frame 
shall be dropped; 

b) Otherwise, if the FQC value of the lu UP frame is set to "frame bad" or "frame bad due to radio" then the frame 
shall be dropped, regardless of the CRC check indication; 

c) Otherwise, the frame shall be passed to radio interface protocols. 

NOTE: The case where SRNC receives a frame with the FQC set to "frame bad due to radio" (respectively: 

"frame bad"), corresponds to a TrFO (respectively: TFO) case. The frame is then trashed by the receiving 
RNC since there is currently no means to pass the frame quality indicator down to the UE. 

6.5 Elementary procedures 

6.5.1 Transfer of User Data procedure 
6.5.1.1 Successful operation 

The purpose of the Transfer of User Data procedure is to transfer lu UP frames between the two lu UP protocol layers 
at both ends of the lu interface. Since an lu UP instance is associated to a RAB and a RAB only, the user data being 
transferred only relate to the associated RAB. 

The procedure is controlled at both ends of the lu UP instance i.e. SRNC and the CN. Exceptions in case of TrFO, 
where the partner peer entity does not reside within the serving CN node are described in subclause 4.1 and TS 23.153 
[13]. 
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The Transfer of User Data procedure is invoked whenever user data for that particular RAB needs to be sent across the 
lu interface. 

The procedure is invoked by the lu UP upper layers upon reception of the upper layer PDU and associated control 
information: RFCI. 

The upper layers may deliver a frame quality classification information together with the RFCI. 

The NAS Data Streams specific functions makes the padding of the payload (if needed) so that the lu UP frame payload 
will be an integer number of octets. Then the NAS Data Streams specific functions perform, if needed, CRC calculation 
of the lu frame payload and passes the lu UP frame payload down to the Frame Handler function together with the 
RFCI. 

The Frame Handler function retrieves the frame number from its internal memory, formats the frame header and frame 
payload into the appropriate PDU Type and sends the lu UP frame PDU to the lower layers for transfer across the lu 
interface. If the UTRAN initialises the RAB it shall base the selection of the PDU type (in both directions) on the 
reliability attributes (see TS 25.413 [3]) for the RAB. If the reliability attribute Delivery of Erroneous SDUIE equals 
"no-error-detection-consideration" for all subflows then PDU Type 1 shall be used, otherwise PDU Type shall be 
used. 

For RABs with the traffic class conversational or streaming the frame number shall be based on time (stepped at each 
ITI). For RABs with another type of traffic class the frame numbering shall be based on sent lu UP PDU (stepped at 
each sent lu UP PDU). See description of Frame Number IE. 

Upon reception of a user data frame, the lu UP protocol layer checks the consistency of the lu UP frame as follows: 

The Frame Handler function checks the consistency of the frame header and the consistency of the frame 
number. If a frame loss is detected due a gap in the sequence of the received frame numbers (for a RAB where 
frame numbers does not relate to time), this shall be reported to the Procedure Control function. If correct, the 
Frame Handler function stores the frame number and passes the lu UP frame payload and associated CRC, if any 
to the NAS Data Streams specific functions. The received RFCI is passed to the Procedure Control function; 

The NAS Data Streams specific functions check the payload CRC, if any. If the RFCI is correct (i.e. RFCI is 
used at Initialisation) and matches the lu UP frame payload (i.e. frame payload is not too short for the RFCI) as 
indicated by the Procedure Control functions, the NAS Data Streams specific functions removes the padding bits 
and the spare extension field when present from the lu UP frame payload based on the RFCI information. Then 
the NAS Data Streams specific functions forwards to the upper layers the RFCI and the payload. 
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Figure 7: Successful Transfers of User Data 



6.5.1.2 



Unsuccessful operation 



If the lu UP frame carrying the user data is incorrectly formatted or cannot be correctly treated by the receiving lu UP 
protocol layer, the lu UP protocol layer shall either discard the frame or pass it to the upper layers with a frame 
classification indicating a corrupted frame. This decision is based on configuration data of the lu UP instance for that 
particular RAB (i.e. if the RAB requests delivery of corrupted frame). 

If the lu UP protocol layer detects a frame loss because of a gap in the received frame number sequence while the frame 
number does not relate to time (see description of Frame Number IE), the receiving lu UP protocol layer shall report 
this to the Procedure Control function. 
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Figure 8: Unsuccessful Transfers of User Data: 1) Corrupted Frame, 2) Detection of Frame loss 

6.5.2 Initialisation procedure 



6.5.2.1 



Successful operation 



This procedure is mandatory for RABs using the support mode for predefined SDU size. The purpose of the 
Initialisation procedure is to configure both termination points of the lu UP with RAB Subflows Combinations, RFCIs, 
and associated RAB Sub Flows SDU sizes necessary to be supported during the transfer of user data phase. 

Additional parameters may also be passed, such as the Inter PDU Timing Interval (IPTI) information. 

The Initialisation procedure may be controlled at both end of the lu access point, i.e. the CN and UTRAN. 

The Initialisation procedure is invoked whenever indicated by the lu UP Procedure Control function e.g. as a result of a 
relocation of SRNS or at RAB establishment over lu or if the CN decides to resolve RFCI mismatch in case of TrFO 
(see TS 23.153 [13]). The Initialisation procedure shall not be re-invoked by the SRNC for the RAB without a RAB 
modificadon requested via RANAP (TS 25.413 [3]). 

When this procedure is invoked all other lu UP procedures are suspended until termination of the Initialisation 
procedure. 

The lu UP protocol entity invoking this procedure shall indicate the lu UP Mode version of the INITIALISATION 
control frame it uses in the lu UP Mode Version field. It shall also indicate the lu UP Mode versions it proposes among 
the versions the CN requested for the related RAB and which it supports in the lu UP Mode Versions Supported field. 
The sender should use the lowest lu UP Mode version for the initialisation that has enough information to initialise the 
highest proposed protocol version. 

The invoking entity allocates a RAB sub-Flow Combination indicator (RFCI) to each RAB sub-Flow Combination it 
initialises. One requirement on which RAB sub-Flow Combinations to initialise, is that all requested compound RAB 
sub-Flow Combination SDU sizes shall be configured, except in the case when also version 1 of the user plane mode 
was included as an alternative in the request over RANAP. In that case, it is allowed to initialise just a subset of the 
requested RAB sub-Flow Combinations, however at least one of the requested RAB sub-Flow Combinations equal or 
above the guaranteed bitrate shall be initialised. The association of indicators to RAB Flow Combinations is valid for 
both the uplink and downlink direction in the lu UP until a new Initialisation procedure is performed or the connection 
is terminated. 

The Procedure Control function may also generate additional lu UP protocol parameters necessary for the RAB service 
to operate properly over lu. 

To each RAB sub-Flow combination indicator is associated the size of each RAB sub-Flow SDU of that combination. 
The list of RAB sub-Flow Combination Indicators and their respective SDU sizes constitutes the RAB sub-Flow 
Combination set passed over the lu UP in the INITIALISATION control frame i.e. into an appropriate lu UP PDU 
Type. 

The first RAB Sub-flow Combination proposed in the list of RAB Sub-Flow Combinations corresponds to the 
maximum bit rate allowed to be used when starting the communication phase i.e. until the first RATE CONTROL 
control frame occurs. The RAB Sub-flow Combinations for rates below the guaranteed bit rate as specified in the RAB 
parameters (indicated to the lu-UP at the RNC) shall not be used as the first RAB Sub-flow Combination in the 
proposed list of RAB Sub-Flow Combinations. 
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Any RAB Sub-Flow Combination of the set that is initialised shall be supported by the two lu UP termination points 
and may optionally be used by the sender (except for the first in the list that shall be used when starting). In particular, 
the use by the sender of the RFC "NO_DATA" is optional even when it is included in the Initialisation procedure. 

Conversely, any RAB Sub-Flow Combination that is not part of the initialised set shall not be used even if supported. In 
particular, the two lu UP termination points shall be capable of operating without the use of the RFC "NO_DATA" . 

The complete set of information is framed by the lu UP Frame Handler function and transferred in an lu UP 
INITIALISATION control frame. If needed, the INITIALISATION control frame CRC is calculated and set 
accordingly in the respective frame field. 

A supervision timer T initIS started after sending the lu UP INITIALISATION control frame. This timer supervises the 
reception of the initialisation acknowledgement frame. 

Upon reception of a frame indicating that an Initialisation procedure is active in the peer lu UP entity, the lu UP 
protocol layer forwards the whole protocol information contained in the INITIALISATION control frame to the upper 
layers. It also stores the RAB sub-Flow Combination set (and thus replaces a possible previous set) in order to control 
during the transfer of user data, that the lu UP payload is correctly formatted (e.g. RFCI matches the expected lu UP 
frame payload total length). The peer lu UP entity receiving the INITIALISATION control frame shall choose a version 
that it supports among the proposed versions indicated by the sender for which it has enough initialisation information. 

If the INITIALISATION control frame is correctly formatted and treated by the receiving lu UP protocol layer, and at 
least one of the proposed versions is supported, this latter sends an INITIALISATION POSITIVE 
ACKNOWLEDGEMENT frame using the version of the lu UP Mode that is chosen. 

Upon reception of an initiahsation acknowledgement frame, the lu UP protocol layer in the SRNC stops the supervision 
timer Tinit- 

If the Initialisation procedure requires that several frames are to be sent, each frame shall be acknowledged individually 
(i.e. any frame to be sent shall wait for the acknowledgement of the previous sent frame to be received before being 
sent. The supervision timer shall be used individually for each frame being sent. 

The successful operation of the Initialisation procedure may require that one or several chained frames are positively 
acknowledged. The number of INITIALISATION control frames in such a chain shall not exceed 4. Each chained 
frame shall be positively acknowledged before the one with the next frame number can be sent. 

The PDU Type 14 Frame Number IE of an INITIALISATION control frame shall always be set to "0" when the chain 
has only one frame. When several INITIALISATION control frames are used in a chain the PDU Type 14 Frame 
Number IE shall be set to "0" for the first one and incremented by one in the sending direction for each new frame in the 
chain. The positive acknowledgement or negative acknowledgement shall carry the frame number of the frame being 
acknowledged. 

Upon reception of an INITIALISATION NEGATIVE ACKNOWLEDGEMENT control frame, an erroneous 
acknowledgement or at timer T init expiry, the lu UP protocol entity controlling the Initialisation procedure shall reset 
and restart the T i^it supervision timer and repeat one INITIALISATION control frame with the same frame number. 
The repetition shall be performed up to N init times, N init being chosen by the operator (default N init = 3). The N init 
(maximum number of allowed repetition) is the aggregate count for each frame in the chain and is restart each time a 
frame is positively acknowledged. 
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Figure 9: Successful Initialisation of lu UP for m RFCIs 
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6.5.2.2 Unsuccessful operation 

If the INITIALISATION control frame is incorrectly formatted and cannot be correctly treated by the receiving lu UP 
protocol layer, this latter sends an INITIALISATION NEGATIVE ACKNOWLEDGEMENT control frame. 

If the receiver does not support the lu UP Mode version used for the Initialisation procedure, it shall send a negative 
acknowledgement using the highest version it supports among the versions proposed by the sender. If none of the 
proposed versions are supported, the receiver shall respond with a negative acknowledgement using the highest version 
it supports. 

After N init successive negative acknowledgment, erroneous acknowledgment or T inet expiry for INITIALISATION 
control frames having the same frame number, the Initialisation procedure is unsuccessfully terminated and the lu UP 
protocol layers in RNC take appropriate local actions. 
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Figure 10: Unsuccessful initialisation of lu UP: 1) N init negative acknowledgement 

or 2) N INIT expiries of timer Tinit 

6.5.3 lu Rate Control procedure 
6.5.3.1 Successful operation 

The purpose of the lu Rate Control procedure is to signal to the peer lu UP protocol layer the maximum rate over lu in 
the reverse direction of the sent RATE CONTROL control frame. 

The Rate Control procedure over lu UP is normally controlled by the entity controlling the rate control over UTRAN 
i.e. the SRNC. The lu Rate Control procedure is invoked whenever the SRNC decides that the maximum rate permitted 
downlink over lu shall be modified, or when a RATE CONTROL control frame is received from the CN. Within the 
context of TrFO the SRNC may also receive RATE CONTROL control frames from the TrFO partner. 

The rates that can be controlled by the SRNC are all the rates that are defined by the lu-Initialisation procedure and 
which are above the guaranteed bitrate specified in the RAB parameters (indicated to the lu UP at the RNC). Rates 
below or equal to the guaranteed bitrate, e.g. the lowest speech rate or the SID frames, cannot be controlled (i.e. cannot 
be forbidden) by the SRNC (exceptionally, in case of version 1 any of the initialised rates equal to or above the 
guaranteed bitrate can be controlled). 

The procedure can be signalled at any time when Transfer of User Data procedure is not suspended by another 
Procedure Control function. When the user plane was initiated due to SRNS relocation reasons no rate control shall be 
signalled before the reception of the relocation execution trigger (see TS 25.413 [3]). At the reception of the relocation 
execution trigger the RNC shall start the lu Rate Control procedure. This enables both TrFO partners to exchange 
current maximum rates and proceed user data transport based on latest rate decisions. 

The Procedure Control function upon request of upper layer prepares the RATE CONTROL control frame payload 
containing the maximum rate of the reverse direction of the RATE CONTROL control frame. To align the lu Rate 
Control procedure with version 1 of the lu UP protocol the permitted maximum rate is given as a set of RFCI indicators, 
that shall contain the maximum rate and all rates below the maximum rate, i.e. all rate controllable and non rate 
controllable rates. In the context of TrFO and TFO the lu Rate Control procedure may also be controlled by a remote 
peer. 

The Frame Handler function calculates the frame CRC, formats the frame header into the appropriate PDU Type and 
sends the lu UP frame PDU to the lower layers for transfer across the lu interface. 
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A supervision timer Trc is started after sending the lu UP RATE CONTROL control frame. This timer supervises the 
reception of the rate control acknowledgement frame. Upon reception of a rate control acknowledgement frame, the lu 
UP protocol layer in the SRNC stops the supervision timer Trc- 

Upon reception of a RATE CONTROL control frame, the lu UP protocol layer checks the consistency of the lu UP 
frame as follows: 

The Frame Handler function checks the consistency of the frame header and associated CRC. If correct, the 
Frame Handler function passes Procedure Control part to the procedure control functions; 

The Procedure Control functions check that all RFCIs in the initial RFCI set are indicated as either allowed or 
barred. If the whole rate control information is correct, the Procedure Control functions passes the rate control 
information to the NAS Data Streams specific functions; 

- The NAS Data Streams specific functions forward to the upper layers the complete protocol data in a lu-UP- 
Status indication primitive; 

Upon reception of the lu-UP-Status request primitive, the Procedure Control functions shall acknowledge the 
RATE CONTROL control frame by including its own maximum rate control information i.e. the permitted rates 
in the reverse direction of the RATE CONTROL ACK message. 
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Figure 1 1 : Successful Rate Control 
Figure 12: Void 



6.5.3.2 



Unsuccessful operation 



If the lu UP protocol layer receives a RATE CONTROL control frame that is badly formatted or corrupted, it shall 
ignore the RATE CONTROL control frame, but send a RATE CONTROL NEGATIVE ACKNOWLEDGEMENT 
control frame back (figure 13a). 
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Figure 13a: Negative Acknowledgement received from the peer 

If the lu UP in the SRNC detects that the RATE CONTROL control frame has not been correctly interpreted or 
received (e.g. the observed rate is outside the set of permitted rates in the reverse direction of the RATE CONTROL 
control frame (figure 13b), or a RATE CONTROL NEGATIVE ACKNOWLEDGEMENT control frame has been 
received, or no RATE CONTROL POSITIVE ACKNOWLEDGEMENT control frame was received before the 
supervision timer Trc expires (Figure 13c)), the lu UP shall retrigger a lu Rate Control procedure. If after N rc 
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repetitions, the error situation persists, the lu UP protocol layers (sending and receiving) take the appropriate local 
actions. 
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Figure 13: Unsuccessful Transfer of rate control from RNC: 1) Frame loss 2) Corrupted Frame 
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Figure 13b: Unsuccessful Transfer of rate control: undetected error 
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Figure 13c: Unsuccessful Transfer of rate control: lost rate control 

6.5.3.2A Frequent Rate Control Procedures 

Typically a new RATE CONTROL control frame should not be sent in the same direction before the previous lu Rate 
Control procedure was terminated successfully. 
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If for some reasons (e.g. frequently received RATE CONTROL control frames from the CN in a TFO connection to 
GSM) a RATE CONTROL control frame has to be sent before the previous lu Rate Control procedure was terminated 
successfully, then the previous lu Rate Control procedure is defined as terminated successfully: the supervision timer 
Trc shall be stopped and acknowledgement frames (positive or negative) for the previous RATE CONTROL control 
frame shall be ignored, i.e. only the most recent lu Rate Control procedure shall be active in the same direction. 
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Figure 14: Frequent Rate Control: only most recent one is important 



Figure 15: Void 



6.5.4 Time Alignment procedure 



6.5.4.1 



Successful operation 



The purpose of the Time Alignment procedure is to minimise the buffer delay in RNC by controlling the downlink 
transmission timing in the peer lu UP protocol layer entity. 

The Time Alignment procedure is controlled by SRNC. 

The Time Alignment procedure is invoked whenever the SRNC detects the reception of lu UP PDU at an inappropriate 
timing that leads to an unnecessary buffer delay. The actual detection of the trigger in SRNC is an internal SRNC matter 
and is out of the scope of the present document. 

The lu UP protocol layer entity in SRNC indicates the peer entity the necessary amount of the delay or advance 
adjustment in the number of 500 |as steps. 

A supervision timer T-pA is started after sending the lu UP TIME ALIGNMENT control frame. This timer supervises the 
reception of the time alignment acknowledgement frame. 

The requested lu UP protocol layer entity in the peer node adjusts the transmission timing by the amount as indicated by 
SRNC. 

If the TIME ALIGNMENT control frame is correctly formatted and treated by the receiving lu UP protocol layer and 
the time alignment is treated correctly by the upper layers, this latter sends an time alignment acknowledgement frame. 

Upon reception of a time alignment acknowledgement frame, the lu UP protocol layer in the SRNC stops the 
supervision timer Txa- 

The procedure can be signalled at any time when transfer of user data is not suspended by another control procedure. 
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RNC 



CN 



User data with bad timing 



TIME ALIGNMENT 



ACK 



User data with adjusted timing 



Figure 15a: Successful Time Alignment 



Figure 16: Void 



6.5.4.2 



Unsuccessful operation 



If the TIME ALIGNMENT control frame could not be handled by the peer side, the peer side should send a NACK 
with a corresponding cause. When the lu UP protocol layer in the SRNC receives a NACK with cause "Time Alignment 
not supported", then the SRNC shall not send additional TIME ALIGNMENT control frames for that RAB (unless the 
lu UP conditions change for that RAB). The cause value "Requested Time Alignment not possible" is used to indicate 
that the requested time alignment was not possible at that moment. At a later moment the SRNC may initiate a new 
TIME ALIGNMENT control frame when needed. If the TIME ALIGNMENT control frame is received by the RNC, it 
shall respond with a NACK with the cause "Time Alignment not supported". 

If the lu UP protocol layer in the SRNC detects that the TIME ALIGNMENT control frame has not been correctly 
inteipreted or received, i.e NACK received or timer expires, and the time alignment need still persists, the lu UP should 
retrigger a Time Alignment procedure. If after N ta repetitions, the error situation persists, the lu UP protocol layers 
take appropriate local actions. 

Upon reception of a TIME ALIGNMENT NEGATIVE ACKNOWLEDGEMENT control frame, the lu UP protocol 
layer in the SRNC stops the supervision timer T-pA- 



RNC J CN 

TIME ALIGNMENT 



1 



2) 



TIME ALIGNMENT NACK 



iL 



after N ta repetitions 



Figure 16a: Unsuccessful Time Alignment: 1) N ta negative acknowledgements 

or 2) N TA expiries of timer Tta 
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Figure 16b: Time Alignment received by the RNC 



6.5.5 Handling of Error Event procedure 



6.5.5.1 



Successful operation 



The purpose of the Handhng of Error Event procedure is to handle the error reporting. Over the lu UP protocol the error 
reports are made with ERROR EVENT control frames. The Handling of Error Event procedure in the lu UP can be 
triggered by: 

An error detected by the lu UP functions (by receiving an erroneous frame or by receiving a frame with 
unknown or unexpected data). In this case an lu UP- Status Indication may be used to inform the upper layers; 

A request by the upper layers. 

When an Error event is reported by an ERROR EVENT control frame the following information shall be included: 

A cause value; 

Error distance (=0 if lu UP function detected, =1 if requested by upper layers). 

Upon reception of an ERROR EVENT control frame the lu UP functions should take appropriate local actions based on 
the cause value. This may include reporting the error to the upper layers with an lu UP status indication. 



RNC/ 
CN 



CN/ 
RNC 



ERROR EVENT 
(Cause value, 
Error distance) 



Figure 15b: Successful Error event 



6.5.5.2 



Unsuccessful operation 



If the ERROR EVENT control frame is incorrectly formatted and cannot be correctly treated by the receiving lu UP 
protocol layer appropriate local actions are taken (e.g. upper layers are informed). An error in an ERROR EVENT 
control frame should not generate the sending of a new ERROR EVENT control frame. 
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Figure 16c: Unsuccessful Transfer of ERROR EVENT control frame: 1) Frame loss 2) Corrupted 

Frame 

6.5.6 Frame Quality Classification procedure 

The Frame Quality Classification procedure uses the services of the Transfer of User Data procedure to exchange across 
the lu UP interface the Frame Quality Classification information. 

CN 



TRANSFER OF USER DATA p|^Q 
(FQC, RFC!, payload) 



CN/ 
INC 

► 



TRANSFER OF USER DATA 
(FOC, RFCI, payload) 



Figure 17: Successful Transfers of User Data with FOC information 

6.6 Elements for lu UP communication in Support mode 
6.6.1 General 

In the present document the structure of frames will be specified by using figures similar to figure 18. 
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Bits 


-z. 

CO -> 
o 






7 


6 


5 


4 


3 


2 


1 







Field 1 


Field 2 


1 


Octet 1 


Header 
part 


Field 3 


Field 4 


2 


Octet 2 
Octet 3 


Field 4 continue 


Spare 


Field 6 


2 


Octet 4 
Octet 5 


Payload 
part 


Field 6 continue 


Padding 


Spare extension 


0-m 





Figure 18: Example frame format 

Unless otherwise indicated, fields which consist of multiple bits within an octet will have the more significant bit 
located at the higher bit position (indicated above frame in figure 18). In addition, if a field spans several octets, more 
significant bits will be located in lower numbered octets (right of frame in figure 18). 

On the lu interface, the frame will be transmitted starting from the lowest numbered octet. Within each octet, the bits 
are sent according decreasing bit position (bit position 7 first). 

Spare bits should be set to "0" by the sender and should not be checked by the receiver. 

The header part of the frame is always an integer number of octets. The payload part is octet rounded (by adding 
'Padding' when needed). 

The receiver should be able to remove an additional spare extension field that may be present at the end of a frame. See 
description of Spare extension field. 

6.6.2 Frame Format for predefined size SDUs 



6.6.2.1 



PDU Type 



PDU Type is defined to transfer user data over the lu UP in support mode for pre-defined SDU sizes. Error detection 
scheme is provided over the lu UP for the payload part. 

The following shows the lu frame structure for PDU TYPE data frame of the lu UP protocol at the SAP towards the 
transport layers (TNL-SAP). 
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Bits 


-z. 

en -^ 




7 


6 


5 


4 


3 


2 


1 









PDU Type (=0) 


Frame Number 


1 


Frame 

Control 

Part 


FQC 


RFCI 


1 


Header CRC 


Payload CRC 


2 


Frame 
Check 
Sum Part 


Payload CRC 


Payload Fields 


0-n 


Frame 

Payload 

part 


Payload Fields 


Padding 


Spare extension 


0-4 



Figure 19: lu UP PDU Type Format 

The lu UP PDU TYPE data frame is made of three parts: 

1) lu UP Frame Control part (fixed size); 

2) lu UP Frame Check Sum part (fixed size); 

3) lu UP Frame Payload part (pre-defined SDU sizes rounded up to octets [Note; this does not consider the usage of 
spare extension field]). 

The lu UP Frame Control Part and the lu UP Frame Check Sum Part constitute the lu UP PDU Type Frame Header. 

6.6.2.2 PDU Type 1 

PDU Type 1 is defined to transfer user data over the lu UP in support mode for pre-defined SDU sizes when no payload 
error detection scheme is necessary over lu UP (i.e. no payload CRC). 

The following shows the lu frame structure for PDU TYPE 1 data frame of the lu UP protocol at the SAP towards the 
transport layers (TNL-SAP). 
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Bits 


-z. 

en -^ 




7 


6 


5 


4 


3 


2 


1 









PDUType(=1) 


Frame Number 


1 


Frame 

Control 

Part 


FQC 


RFCI 


1 


Header CRC 


Spare 


1 


Frame 
Check 
Sum Part 


Payload Fields 


0-n 


Frame 

Payload 

part 


Payload Fields 


Padding 


Spare extension 


0-4 



Figure 20: lu UP PDU Type 1 Format 

The lu UP PDU TYPE 1 data frame is made of three parts: 

1) lu UP Frame Control part (fixed size); 

2) lu UP Frame Check Sum part (fixed size); 

3) lu UP Frame Payload part (pre-defined SDU sizes, rounded up to octets [Note: this does not consider the usage 
of spare extension field]). 

The lu UP Frame Control Part and the lu UP Frame Check Sum Part constitute the lu UP PDU Type 1 Frame Header. 

6.6.2.3 PDU Type 14 

6.6.2.3.1 General 

PDU Type 14 is defined to perform control procedures over the lu UP in support mode for pre-defined SDU sizes. The 
control procedure is identified by the procedure indicator. The Frame Payload contains the data information related to 
the control procedure. 

Figure 21 shows the lu frame structure for PDU Type 14 of the lu UP protocol at the SAP towards the transport layers 
(TNL-SAP). 
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Bits 


-z. 
o 3 

en -> 
O 




7 


6 


5 


4 


3 


2 


1 







PDUType(=14) 


Ack/Nack (=0, 
i.e. procedure) 


PDUTypeU 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator 


1 


Header CRC 


Payload CRC 


1 


Frame 
Checksu 
m Part 


Payload CRC 


1 


Reserved for procedure data 


0-n 


Frame 

payload 

part 


Spare extension 


0-32 



Figure 21 : lu UP PDU Type 14 Format for procedure sending 

The lu UP PDU Type 14 is made of three parts: 

1) lu UP Frame Control part (fixed size); 

2) lu UP Frame Check Sum part (fixed size); 

3) lu UP Frame Payload part (variable length, rounded up to octet). 

The lu UP Frame Control Part and the lu UP Frame Check Sum Part constitute the lu UP PDU Type 14 Frame Header. 



6.6.2.3.2 



Positive Acknowledgement 



When the PDU Type 14 is used to positively acknowledge a control procedure, the PDU Type 14 frame takes the 
following structure at the TNL-SAP. 
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Bits 


-z. 
o 3 

en -> 
O 




7 


6 


5 


4 


3 


2 


1 







PDUType(=14) 


Ack/Nack(=1, 
i.e. Ack) 


PDUTypeU 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator 

(indicating the procedure being 
positively acknowledged) 


1 


Header CRC 


Spare 


1 


Frame 
Checksu 
m Part 


Spare 


1 


Spare extension 


0-32 


Frame 

Payload 

part 



Figure 22: lu UP PDU Type 14 Format for positive acknowledgement 

The lu UP Frame Control Part and the lu UP Frame Check Sum Part constitute the lu UP PDU Type 14 Frame Header 
for positive acknowledgement. 



6.6.2.3.3 



Negative Acknowledgement 



When the PDU Type 14 is used to negatively acknowledge a control procedure, the PDU Type 14 frame takes the 
following structure at the TNL-SAP. 



Bits 


-z. 
o 3 

en -> 
O 




7 


6 


5 


4 


3 


2 


1 







PDU Type (=14) 


Ack/Nack (=2, 
i.e. Nack) 


PDU Type 14 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator 

(indicating the procedure being 
negatively acknowledged) 


1 


Header CRC 


Spare 


1 


Frame 
Checksu 
m Part 


Spare 


1 


Error Cause value 


Spare 


1 


Frame 

payload 

part 


Spare extension 


0-32 



Figure 23: lu UP PDU Type 14 Format for negative acknowledgement 

The lu UP Frame Control Part and the lu UP Frame Check Sum Part constitute the lu UP PDU Type 14 Frame Header 
for negative acknowledgement. 
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6.6.2.3.4 



Procedures Coding 



6.6.2.3.4.1 Initialisation 

Figure 24 specifies how the INITIALISATION control frame is coded. 



Bits 


-z. 
o 3 




7 


6 


5 


4 


3 


2 


1 









PDU Type (=14) 


Ack/Nack (=0. 
I.e. Procedure) 


PDU Type 14 
Frame Number 


1 


Frame 
Control 
Part 


lu UP IVIode version 


Procedure Indicator (=0) 


1 


Header CRC 


Payload CRC 


2 


Frame 

Checksum 

part 


Payload CRC 


Spare 


Tl 


Number of subflows per 
RFCI (N) 


Chain 
Ind 


1 


Frame 

payload 

part 


LRI 


LI 


1"RFCI 


1 


Length of subflow 1 


1 or 2 
(dep. LI) 


Length of subflow 2 to N 


(N-1)x(1 
or 2) 


LRI 


LI 


2"'' RFCI 


1 


Length of subflow 1 


1 or 2 
(dep. LI) 


Length of subflow 2 to N 


(N-1)x(1 
or 2) 






IPTIof 1"RFCI 




or M/2 

(M: 

Number 

of RFCIs 

in frame). 

Ended by 

4 
padding 
bits if M 
is odd. 




IPTI of M* RFCI or Padding 


lu UP Mode Versions supported (bitmap) 


2 


Data PDU type 


Spare 


1 


Spare extension 


0-32 



Figure 24: lu UP PDU Type 14 used for Initialisation 
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6.6.2.3.4.2 



Rate Control 



6.6.2.3.4.2.1 Rate Control procedure 

Figure 25 specifies how the RATE CONTROL control frame is coded. 



Bits 


si 

o 




7 


6 


5 


4 


3 


2 


1 







PDUType(=14) 


Ack/Nack (=0, 
i.e. Procedure) 


PDUTypeU 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator (=1) 


1 


Header CRC 


Payload CRC 


1 


Frame 
Checksu 

m Part 


Payload CRC 


1 




Spare 


Number of RFCI Indicators (P) 


1 


Frame 

payload 

part 


RFCIO 
Ind. 


RFCI1 
Ind 




RFCI 
P-1 
Ind 


Padding 


0-n 


Spare extension 


0-32 





Figure 25: lu UP PDU Type 14 Format used for Rate Control 

6.6.2.3.4.2.2 Rate Control positive acknowledgement 

Figure 25a specifies how the RATE CONTROL POSITIVE ACKNOWLEDGEMENT control frame is coded. 
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Bits 


-z. 

en -> 
O 




7 


6 


5 


4 


3 


2 


1 







PDUType(=14) 


Ack/Nack(=1, 
i.e. Ack) 


PDUType14 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator 

(indicating the procedure being 
positively acknowledged) 


1 


Header CRC 


Spare 


1 


Frame 
Checksu 
m Part 


Spare 


1 


Spare 


Number of RFCI Indicators (P) 


1 


Frame 

Payload 

part 


RFCIO 
Ind. 


RFCI1 
Ind 




RFCI 
P-1 
Ind 


Padding 


0-n 


Spare extension 


0- 

(31 -n) 



Figure 25a: lu UP PDU Type 14 Format for positive acknowledgement 

6.6.2.3.4.3 Time Alignment 

Figure 26 specifies how the TIME ALIGNMENT control frame is coded. 



Bits 


-z. 

O ^ 

en -> 
O 




7 


6 


5 


4 


3 


2 


1 







PDU Type (=14) 


Ack/Nack(=0) 


PDU Type 14 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator (=2) 


1 


Header CRC 


Payload CRC 


1 

1 


Frame 
Checksu 
m Part 


Payload CRC 


Time alignment 


1 


Frame 

payload 

part 


Spare extension 


0-32 



Figure 26: lu UP PDU Type 14 Format used for Time Alignment 
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6.6.2.3.4.4 Error Event 

Figure 27 specifies how the ERROR EVENT control frame is coded. 



Bits 


si 

en -> 
O 




7 


6 


5 


4 


3 


2 


1 







PDUType(=14) 


Ack/Nack(=0) 


PDUType14 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator (=3) 


1 


Header CRC 


Payload CRC 


1 
1 


Frame 
Checksu 
m Part 


Payload CRC 


Error distance 


Error Cause value 


1 


Frame 

payload 

part 


Spare extension 


0-32 



Figure 27: lu UP PDU Type 14 Format used for Error Event 



6.6.3 Coding of information elements in frames 



6.6.3.1 



PDU Type 



Description: The PDU type indicates the structure of the lu UP frame. The field takes the value of the PDU Type it 
identifies: i.e. "0" for PDU Type 0. The PDU type is in bit 4 to bit 7 in the first octet of the frame. PDU type is used in 
all frames in support mode for predefined SDU sizes. 

Value range: {0-1 and 14 in use, 2-13: reserved for future PDU types, 15=reserved for future PDU type extensions) 

Field length: 4 bits 

6.6.3.2 Ack/Nack 

Description: The Ack/Nack field tells if the frame is: 

A control procedure frame; 

A positive acknowledgement (ACK) of a control procedure frame; 

A negative acknowledgement (NACK) of a control procedure frame. 
Value range: {O=control procedure frame, 1=ACK, 2=NACK, 3=reserved) 
Field length: 2 bits 
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6.6.3.3 Frame Number 

Description: The lu UP frame numbering is handled by a Frame Number. The frame numbering can be based on either 
time or sent lu UP PDU. In case the frame numbering is based on time the purpose of the frame number is to be of help 
in handling the Time Alignment functionality. When the frame number is based on time, the Frame number set in the 
PDU header is incremented by one (modulo 16) at each new ITI. The Frame number set in the PDU header shall be 
based on the timing of the source. The source is where the original payload was created. Two packets that were 
consecutive at the source shall not have the same frame number assigned. In case the Frame number relates to sent lu 
UP PDU the purpose of the Frame Number is to provide the receiving entity with a mechanism to keep track of lost lu 
UP frames. When the frame number is based on sent lu UP PDU, the Frame number is incremented by one (modulo 16) 
for each sent lu UP PDU. For a given user data connection, there is no relations between the frame numbers of frames 
sent in the downlink direction and the frame numbers of frames sent in the uplink direction. 

In the case the Frame Number relates to sent lu UP PDU, the following applies; 

Frame loss is when an incoming PDU frame has a frame number that is equal to (previous PDU frame number + 2) 
modulo [max. PDU frame number +1]. This indicates that one and only one PDU frame has been lost. 

Unexpected frame number is when an incoming PDU does not have the expected frame number and is not 
considered as a Frame Loss. 

Value range: {0-15). 

Field length: 4 bits. 

6.6.3.4 PDU Type 14 Frame Number 

Description: The lu UP frame numbering is handled by a Frame Number. The purpose of the PDU Type 14 Frame 
Number is to provide the receiving entity with a mechanism to keep track of lost lu UP frames. The PDU Type 14 
Frame Number shall be managed as one single counter for all control procedure functions of a RAB. The sender shall 
increment this number by one (modulo 4) for each sent lu UP Type 14 PDU starting with value for the first PDU Type 
14 INITIALISATION control frame sent out of the initialisation procedure. The counter shall be reset to in case a new 
initialisation takes place. It is also used to relate the acknowledgment frame to the frame being acknowledged i.e. the 
same PDU Type 14 Frame Number is used in the positive or negative acknowledgement frame as the one used in the 
frame being acknowledged. 

The PDU Type 14 Frame Number shall be handled independently per direction, i.e. control frames other than 
acknowledgment frames shall be numbered independently per direction. 

The following applies for PDU Type 14 Frame Number: 

Frame loss is when an incoming PDU frame has a frame number that is equal to (previous PDU frame number + 2) 
modulo [max. PDU frame number +1]. This indicates that one and only one PDU frame has been lost. 

Unexpected frame number is when an incoming PDU does not have the expected frame number and is not 
considered as a Frame Loss. 

Upon detection of frame loss or unexpected PDU Type 14 Frame Number in a procedure other than initialisation, the 
receiving entity shall still consider the frame as valid and handle it normally e.g. treat it and send an acknowledgement 
frame when appropriate. 

Value range: {0-3}. 

Field length: 2 bits. 

6.6.3.5 Frame Quality Classification (FQC) 

Description: Frame Quality Classification is used to classify the lu UP frames depending on whether errors have 
occurred in the frame or not. Frame Quality Classification is dependent on the RAB attribute Delivery of erroneous 
SOU IE. 

Value range: {0=frame good, l=frame bad, 2=frame bad due to radio, 3=spare}. 

Field length: 2 bits. 
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6.6.3.6 RAB sub-Flow Combination Indicator (RFCI) 

Description: The RFCI identifies the structure of the payload. This can be used to specify the sizes of the subflows. 
Value range: {0-62, 63=RFCI not applicable). 
Field length: 6 bits. 

6.6.3.7 Procedure Indicator 

Description: The Procedure Indicator identifies the control procedure in the current frame. 
Value range: {O=initialisation, l=rate control, 2=time alignment, 3=error event, 4-15=reserved}. 
Field length: 4 bits. 

6.6.3.8 Header CRC 

Description: This field contains the CRC of all fields in Frame Control Part. The CRC is a 6-bit checksum based on the 
generator polynom G(D) = D +D +D +D h-D'h-1, see subclause 6.7.7. With this CRC all error bursts shorter than 7 bits 
are detected, as well as all odd number of bits faulty (and two-bit faults) when the protected area is shorter than 24 bits, 
(max 3 octets). 

Field length: 6 bits. 

6.6.3.9 Payload CRC 

Description: This field contains the CRC of all the fields (including Padding and possible Spare extension) of the 
Frame Payload Part. The CRC is a 10 bit checksum based on the generator polynom G(D) = D'"h- DVD^h-D h-D'h-1, see 
subclause 6.7.7. With this CRC all error bursts shorter than 1 1 bits are detected, as well as all odd number of bits faulty 
(and two-bit faults) when the protected area is shorter than 500 bits (max 62 octets). 

Field length: 10 bits. 

6.6.3.10 Chain Indicator 

Description: Chain indicator is used to indicate whether the control procedure frame is the last frame related to the 
control procedure. 

Value range: {0=this frame is the last frame for the procedure, l=additional frames will be sent for the procedure}. 

Field length: 1 bit. 

6.6.3.11 Number of Subflows per RFCI 

Description: Number of Subflows per RFCI field indicates the number of subflows the RAB is made of. It is used to 
decode the SOU size information data lengths. All RFCs consist of the same number of subflows within a specific 
RAB. 

Value range: {0=reserved, 1-7}. 

Field length: 3 bits. 

6.6.3.12 Length Indicator (LI) 

Description: Length Indicator, indicates if 1 or 2 octets is used for the RAB subflow size information. 
Value range: {O=one octet used, l=two octets used}. 
Field length: 1 bit. 
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6.6.3.13 Number of RFCI Indicators 

Description: Number of RFCI indicators indicates the number of RFCI indicators present in the control procedure 
frame. 

Value range: {0-63}. 

Field length: 6 bits. 

6.6.3.14 RFCI n Indicator 

Description: RFCI n Indicator indicates if the RFCI with value n is allowed or barred (n is a value between 0-62). E.g. 
RFCI 4 Indicator set to "0" indicates that RFCI =4 is allowed, RFCI 5 Indicator set to "1" indicates that RFCI =5 is 
barred, etc... 

Value range: {0=RFCI allowed, 1=RFCI barred}. 

Field length: 1 bit. 

6.6.3.15 Error distance 

Description: Indicates if the error occurred at the error reporting entity (=0) or in a more distant entity. The error 
distance is incremented by one (or kept at its maximum value) when an error report is forwarded. 

0: Reporting local error. 
1 ; First forwarding of error event report. 
2: Second forwarding of error event report. 
3: Reserved for future use. 

Value range: {0: Reporting local error, 1: First forwarding of error event report. 2: Second forwarding of error event, 3: 
Reserved for future use } . 

Field length: 2 bit. 

6.6.3.1 6 Error Cause value 

Description: Cause value is used to indicate what kind of error caused the error. Error cause value is used in 
NEGATIVE ACKNOWLEDGEMENT and ERROR EVENT control frames. 

0: CRC error of frame header. 

1 : CRC error of frame payload. 

2: Unexpected frame number. 

3: Frame loss. 

4: PDU type unknown. 

5: Unknown procedure. 

6: Unknown reserved value. 

7: Unknown field. 

8: Frame too short. 

9: Missing fields. 

10-15: spare. 

16: Unexpected PDU type. 

17: spare. 

18: Unexpected procedure. 

19: Unexpected RFCI. 

20: Unexpected value. 

2\-A\: spare. 

42: Initialisation failure. 

43: Initialisation failure (network error, timer expiry). 

44: Initialisation failure (lu UP function error, repeated NACK). 

45: Rate control failure. 

46: Error event failure. 

47: Time Alignment not supported. 

48: Requested Time Alignment not possible. 
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49: lu UP Mode version not supported. 
50-63; spare. 

Value range: {0-15 Used for syntactical protocol errors, 16-41 Used for semantical protocol errors, 42-63 Used for 
other errors ) . 

Field length: 6 bit. 

6.6.3.17 Padding 

Description: This field is an additional field used to make the frame payload part an integer number of octets when 
needed. Padding is set to "0" by the sender and is not interpreted by the receiver. 

Value range: {0-127). 

Field length: 0-7 bits. 

6.6.3.18 Time alignment 

Description: Time alignment indicates the amount the sending time should be advanced or delayed. 

0: Reserved. 

1: Delay l*500|is. 

80: Delay 80*500)is. 
81-127 Reserved. 
128: Reserved. 
129: Advance l*500lJ,s. 

208: Advance 80*500|is. 
209-255 Reserved. 

Value range: {0: Reserved, 1-80: used for delay, 81-128: Reserved, 129-208 used for advance, 209-255: Reserved). 

Field length: 8 bit. 

6.6.3.19 Spare 

Description: The spare field is set to "0" by the sender and should not be interpreted by the receiver. 
Value range: (0-2"-l). 
Field Length: n bits. 

6.6.3.20 Spare extension 

Description: The spare extension field shall not be sent. The receiver should be capable of receiving a spare extension. 
The spare extension should not be interpreted by the receiver. This since in later versions of the present document 
additional new fields might be added in place of the spare extension. The spare extension can be an integer number of 
octets carrying new fields or additional information; the maximum length of the spare extension field (m) depends on 
the PDU type. 

Value range: 0-2"'**-l. 

Field Length: 0-m octets. For PDU Types in the set {0,1 ), m=4. For PDU Types in the set {14), m=32. 

6.6.3.21 LRI, Last RFC! Indicator 

Description: The Last RFCl Indicator is used to indicate which is the last RFCl in the current INITIALISATION 
control frame. This makes it possible for a receiver to detect a spare extension field. 

Value range: (0: Not last RFCl, 1: Last RFCl in current frame). 
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Field Length: 1 bit. 

6.6.3.22 Length of subflow 

Description: This field indicates the length of the corresponding subflow as number of bits per SDU. 
Value range: (0-255 if LI=0, 0-65535 if LI=1). 
Field Length: 8 or 16 bits (depending on LI). 

6.6.3.23 Tl 

Description: This field indicates if Timing Information is included in the INITIALISATION control frame. 
Value range: {0: IPTIs not present, 1: IPTIs present in frame}. 
Field length: 1 bit. 

6.6.3.24 IPTI of n'^ RFCI 

Description: This field indicates the IPTI value in number of ITIs for the corresponding RFCI (in the same order as the 
RFCIs occur in the INITIALISATION control frame). 

Value range: {0-15}. 

Field length: 4 bits. 

6.6.3.25 lu UP Mode versions supported 

Description: This field indicates the lu UP Mode Versions proposed by the sender for the related RAB for the 
initialisation procedure. Up to 16 lu UP Mode versions can be simultaneously indicated. 

Value range: 

Each bit, in the two octet field, indicates a lu UP Protocol version: (First octet, bit 7) indicates version 16, (Second 
octet, bit 0) indicates version 1 . 

Bit = means "Version not supported, not allowed or not proposed" 

Bit = 1 means "Version supported among the required versions and proposed" 

Field length: 2 octets 

6.6.3.26 lu UP Mode Version 

Description: This field indicates the lu UP Mode version used for type 14 frames. Up to 16 lu UP Mode Versions can 
be available. 

Value range: {1-16} The binary coded value is the version number minus 1 (e.g. version 1 is coded "0000", . . ., version 
16 is coded "1111"). 

Field length: 4 bits 

6.6.3.27 Payload fields 

Description: This field contains the Subflow SDUs, starting with the Subflow 1 SDU. The MSB of the Subflow 1 SDU 
is placed in bit 7 of the first octet (see example in figure 27a). 

Value range: {any value}. 

Field length: Sum of the lengths of the included Subflow SDUs. 
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Bits 


9, ^ 

gl 

CD CD 


7 


6 


5 


4 


3 


2 


1 





Subflow 1 SDU 


1 


Subflow 1 SDU cont. 


Subflow 2 SDU 


1 


Subflow 2 SDU cont. 


Padding 

(Not part of 

"Payload fields") 


1 



Figure 27a: Example of "Payload fields" with two Subflow SDUs 

6.6.3.28 Data PDU type 

Description: This field indicates the PDU type that shall be used (in both directions) for transferring user data. 
Value range: {0: PDU type 0, 1: PDU type 1, 2-15: Reserved for future use}. 
Field length: 4 bits. 

6.6.4 Timers 



This Timer is used to supervise the reception of the initialisation acknowledgement frame from the peer lu UP instance. 
This Timer is set by O&M. 



This Timer is used to supervise the reception of the time alignment acknowledgement frame from the peer lu UP 
instance. This Timer is set by O&M. 



This Timer is used to supervise the reception of the rate control frame from the peer lu UP instance. This Timer is set 
by O&M. 

6.6.5 Maximum values of repetition counters 

NiNIT 

Maximum number of repetitions of an INITIALISATION control frame due to failure at the Initialisation procedure. 

Nrc 

Maximum number of repetitions of a RATE CONTROL control frame due to failure at the Rate Control procedure. 

Nta 

Maximum number of repetitions of a TIME ALIGNMENT control frame due to failure at the Time Alignment 
procedure. 

6.7 Handling of unknown, unforeseen and erroneous protocol 
data 

6.7.1 General 

Error handling in lu UP protocol is applicable only for lu UP in Support mode. 
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The Handling of Error Event procedure is the procedure handhng error reporting. The Handling of Error Event 
procedure in the lu UP can be triggered by: 

An error detected by the lu UP functions (by receiving an erroneous frame or by receiving a frame with 
unknown or unexpected data); 

A request by the upper layers; 

An ERROR EVENT control frame over the lu UP protocol. 

The error can be reported either by: 

An ERROR EVENT control frame over the lu UP protocol; 

An lu UP Status Indication to upper layers (e.g. to be used by O&M). 

When an Error event is reported, either by an lu-UP-Status-Indication, or by an ERROR EVENT control frame the 
following information shall be included: 

Type of the error (syntactical error, semantical error or other error); 

Error distance, i.e. information where the error occurred. 

6.7.2 Error detected by lu UP functions 

When an error is detected within the lu UP functions (by receiving a frame containing erroneous, unknown or 
unexpected data) one of the following actions is taken depending on the type of the error: 

1 . Error indicated to upper layers by sending a lu-UP-Status-Indication primitive; 

2. ERROR EVENT control frame sent; 

3. ERROR EVENT control frame sent and error indicated to upper layers by sending a lu-UP-Status-Indication 
primitive; 

4. No action. 

6.7.3 Request by upper layers 

When the lU UP receives an lu-UP-Status-Request indicating Error event then an ERROR EVENT control frame 
should be sent over the lu UP protocol indicating the appropriate error type. 

6.7.4 Error event frame over the lu UP protocol 

When an ERROR EVENT control frame is received over the lu UP protocol an lu-UP-Status-Indication with 'Error 
event' information indicating the error type should be made to the upper layers. The Error event report contains a 'Cause 
value' that tells the type of the error. The Error event report also contains a field 'Error distance' that tells the distance to 
the entity reporting the error event. The 'Error distance' is "0" when the error is originally sent. When an Error event 
report is forwarded the 'Error distance' is incremented by one. 

6.7.5 Handling of error reports 
6.7.5.1 General 

Figure 28 shows the external error case when the Handling of Error Event procedure is originally triggered by an lu- 
UP-Status-Request. As an action on this the Handling of Error Event procedure sends an ERROR EVENT control 
frame over the lu UP. On the other side the reception of ERROR EVENT control frame triggers the Handling of Error 
Event procedure , and an lu-UP-Status-Indication is sent to upper layers. The handling is symmetrical over the lu UP 
protocol. 
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Figure 28: External error 

Figure 29 shows the internal error case when the Handling of Error Event procedure is originally triggered by the lu UP 
functions. As an action on this the Handling of Error Event procedm^e sends an ERROR EVENT control frame over the 
lu UP. On the other side the reception of ERROR EVENT control frame triggers the Handling of Error Event 
procedure, and an lu-UP-Status-Indication is sent to the upper layers. The handling is symmetrical over the lu UP 
protocol. 
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Figure 29: Internal error 
6.7.5.2 Error distance 

In an ERROR EVENT control frame the error distance has the following meaning: 

0: Error report relates to an lu UP function error at the other side. 

1 ; Error report relates to an error at the other side reported by the upper layers. 

In an lu UP-Status indication the error distance has the following meaning: 

0: Error report relates to an local lu UP function error. 

1: Error report relates to an lu UP function error at the other side. 

2: Error report relates to an error at the other side reported by the upper layers. 
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6.7.6 List of errors in lu UP 



Table 0: List of errors in lu UP 



Error Type 


Error Cause 


Recommended action 

by Handling of Error 

Event procedure 


Possibly 

detected by 

function 


Comment 


Syntactical 


CRC error of Frame 


No action 


NAS Data 


Handled by 




payload (CRC check) 




Streams specific 
functions 


Frame Quality 
Classification, 
when applied 


CRC error of Frame 


lu-UP-Status- 


Frame Handler 


Frame 




Header (CRC check) 


lndication(Error event) 


functions 


discarded 


Unexpected Frame 


lu-UP-Status- 


Frame Handler 


See 6.6.3.3 




Number 


lndication(Error event) 


functions 




Frame loss 


lu-UP-Status- 


Frame Handler 


See 6.6.3.3 






lndication(Error event) 


functions 








and ERROR EVENT 










control frame 






PDU type Unknown 


lu-UP-Status- 


Frame Handler 


Used when 






lndication(Error event) 


functions 


PDU type is 






and ERROR EVENT 




notO, 1, or 14 






control frame 






Unknown procedure 


lu-UP-Status- 


Frame Handler 


Used when 






lndication(Error event) 


functions 


procedure 






and ERROR EVENT 




value is 






control frame 




neither 0, 1, 2, 
or 3 


Unknown reserved value 


See 8.1.1 






Unknown field 






This error 










cause shall not 










be sent. 


Frame too short 


lu-UP-Status- 


Frame Handler 


Used when: 






lndication(Error event) 


functions 


- the length of 






and ERROR EVENT 




the entire 






control frame 




received PDU 
is less than 
the expected 
(calculated) 
PDU header 
length, or 
- the length of 
the payload 
(entire 

received PDU 
minus PDU 
header length) 
is less than the 
expected 
(calculated) 
payload length 


Missing fields 


lu-UP-Status- 


Frame Handler 


This error 






lndication(Error event) 


functions 


cause shall not 






and ERROR EVENT 




be sent. 






control frame 






Semantical 


Unexpected PDU type 


lu-UP-Status- 
lndication(Error event) 
and ERROR EVENT 
control frame 


Frame Handler 
functions 




Unexpected procedure 


lu-UP-Status- 


Frame Handler 








lndication(Error event) 


functions 








and ERROR EVENT 










control frame 






Unexpected RFCI 


lu-UP-Status- 


NAS Data 








lndication(Error event) 


Streams specific 








and ERROR EVENT 


functions 








control frame 







£75/ 



3GPP TS 25.415 version 10.0.0 Release 10 



47 



ETSI TS 125 415 VI 0.0.0 (2011-04) 



Error Type 


Error Cause 


Recommended action 

by Handling of Error 

Event procedure 


Possibly 

detected by 

function 


Comment 




Unexpected value 


lu-UP-Status- 
lndication(Error event) 
and ERROR EVENT 
control frame 


Procedure Control 
functions 




Other error 


Initialisation failure 
(outside lu UP) 


ERROR EVENT control 
frame 


Function outside 
luUP 




Initialisation failure 
(network error, timer 
expiry) 


lu-UP-Status- 
lndication(Error event) 


Procedure Control 
functions 




Initialisation failure (lu UP 
function error, repeated 
NACK) 


lu-UP-Status- 
lndication(Error event) 


Procedure Control 
functions 




Rate control failure 


lu-UP-Status- 
lndication(Error event) 


Procedure Control 
functions 




Error event failure 


lu-UP-Status- 
lndication(Error event) 


Procedure Control 
functions 




Time Alignment not 
supported 


lu-UP-Status- 
lndication(Error event) 


Procedure Control 
functions 




Requested Time 
Alignment not possible 


lu-UP-Status- 
lndication(Error event) 


Function outside 
luUP 




lu UP version not 
supported 


lu-UP-Status- 
lndication(Error event) 


Procedure Control 
functions 





6.7.7 Error detection 



6.7.7.1 



General 



Error detection is provided on frames through a Cyclic Redundancy Check. The CRC for the payload is 10 bits and for 
the header it is 6 bits. 

6.7.7.2 CRC Calculation 

The parity bits are generated by one of the following cyclic generator polynomials: 
gcRC6(D) = D^ + D^ + DV D^ + D' + 1; 
gcRCio(D) = D'" + D' + D' + D* + D' + 1. 

Denote the bits to be protected of a frame by a^,a2,clT,,...,clA{ci^ being the bit with the highest bit position in the 

first octet), and the parity bits by Pj , Pj , P3 , • • • , Pi ■ A, is the length of the protected data and L, is 6 or 10 depending 
on the CRC length. 

The encoding is performed in a systematic form, which means that in GF(2), the polynomial 
ajD^'^^ +a2l>^'^V... + a^_D'' +PiD^ +P2DV... + P5D' + pg 
yields a remainder equal to when divided by gcRC6(D) and the polynomial 
' ^-a^D^ +... + a^.D + p^D + P2D +...+ pgD + p^o 



yields a remainder equal to when divided by gcRcio(D). If A, = , Pi = P2— P3 



Pl,=0. 
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6.7.7.3 



Relation between input and output of the Cyclic Redundancy Check 



The protected bits are left unchanged in the frame. The parity bits for the Header CRC are put in the Header CRC field 
with /7j being the highest bit position of the first octet of the Header CRC field. The parity bits for the Payload CRC are 
put in the Payload CRC field with p^ being the highest bit position of the first octet of the Payload CRC field. 

7 Communication Primitives for the lu UP protocol 

layer 

7.1 Modelling Principle 

The principle illustrated by figure 30 is used for modelling the primitives towards the protocol layer. 

REQUEST 




Figure 30: Modelling principle 



7.2 Primitives towards the upper layers at the RNL SAP 



7.2.1 



General 



The lu UP protocol layer interacts with upper layers as illustrated in the figure above. The interactions with the upper 
layers are shown in terms of primitives where the primitives represent the logical exchange of information and control 
between the upper layer and the lu UP protocol layer. They do not specify or constrain implementations. 

The following primitives are defined: 

- lu-UP-DATA; 

- lu-UP-STATUS; 

- lu-UP-UNIT-DATA. 
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Table 1 : lu UP protocol layer service primitives towards the upper layer at the RNL SAP 



Primitive 


Type 


Parameters 


Comments 


lu-UP-DATA 


Request 


lu-UP-payload 


Subflow 1 SDU, ..., Subflow n SDU 


lu-UP-control 


RFCI 


FQC 


Frame Number 


Indication 


lu-UP-payload 


Subflow 1 SDU, ..., Subflow n SDU 


lu-UP-control 


RFCI 


FQC 


Frame Number 


lu-UP-Status 


Indication 


lu-UP-Procedure-Control 


Error Cause, Error Distance 


Complete protocol data for 
Initialisation, Rate Control, Time 
Alignment and Error Event 






Request 


lu-UP-Procedure-Control 


Error Cause 


Complete protocol data for 
Initialisation, Rate Control, Time 
Alignment and Error Event 




lu-UP-UNIT- 
DATA 


Request 


lu-UP-payload 




Indication 


lu-UP-payload 





Primitive usage is a function of the mode of operation of the lu UP protocol. Table 2 provides the association between 
lu UP primitives towards the upper layers and the lu UP modes of operation. 

Table 2: lu UP protocol layer service primitives related to the lu UP mode 
of operation and function within the mode of operation 



Primitive 


Type 


IVIode of Operation 


lu-UP-DATA 

lu-UP-Status 

lu-UP-UNIT- 
DATA 


Request 


SMpSDU 


Indication 


SMpSDU 


Request 


SMpSDU 


Indication 


SMpSDU 


Request 


TrM 


Indication 


TrM 



7.2.2 lu-UP-DATA-REQUEST 

This primitive is used as a request from the upper layer lu NAS Data Stream entity to send the RAB subflow SDU(s) on 
the established transport connection. This primitive includes the RFCI, the Frame Number and FQC information of the 
payload. 

The lu UP protocol layer forms the lu UP data frame, the lu Data Stream DU being the payload of the lu UP frame, and 
transfers the frame by means of the lower layer services. 
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7.2.3 lu-UP-DATA-INDICATION 

This primitive is used as an indication to the upper layer entity to pass the lu NAS Data Stream User Plane information 
of a received lu UP frame. 

This primitive includes the RFCI, the Frame Number and FQC information of the payload. 

This primitive may also include information aiming at informing the upper layers of a faulty situation that relates to the 
payload included in the primitive. 

7.2.4 lu-UP-STATUS-REQUEST 

This primitive is used to pass control procedure information from the upper layer. 
This primitive shall contain the complete protocol data for the respective procedure. 

7.2.5 lu-UP-STATUS-INDICATION 

This primitive is used to pass control procedure information to the upper layer. 
This primitive shall contain the complete protocol data for the respective procedure. 

7.2.6 lu-UP-UNIT-DATA-REQUEST 

This primitive is used as a request from the upper layer to send an lu UP payload on the established transport 
connection. 

The lu UP protocol layer transfers the lu Data Stream DU by means of the lower layer services without adding any 
protocol header overhead. 

7.2.7 lu-UP-UNIT-DATA-INDICATION 

This primitive is used as an indication to the upper layer entity to pass the lu UP payload. 

7.3 Primitives towards the transport layers at TNL SAP 

7.3.1 General 

Access to the Transport network Layer is performed through a generic SAP: TNL-SAP. 

When the Transport Network upper layer consists of AAL2, the TNL SAP maps onto the AAL-SAP through which 
communication is performed using specific AAL primitives. 

When the Transport Network upper layer consists of GTP-U, the TNL SAP maps onto the GTP-U SAP through which 
communication is performed using generic primitives. 

The choice of communication, specific or generic, through the TNL SAP is fixed by the Radio Network Layer control 
plane logic. This choice is based on the requirements placed by e.g. the RAB characteristics, the CN domain requesting 
the RAB establishment or other operator's choice. 

7.3.2 ATM/AAL2 based Transport layer 
7.3.2.1 General 

When the lu UP protocol layer uses the services of an ATM/AAL2 transport, it uses an established AAL2 connection 
for transferring frames between the peer TNL-S APs at both ends of the lu User plane access points. The Transport 
Network Control Plane over lu handles the signalling to establish and release the AAL2 call connections. 
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7.3.2.2 AAL2 Service Primitives used by the lu UP protocol 

AAL2 services and primitives used at the Service Access Point from the AAL2 layer are shown in table 3. 

Table 3: AAL2 primitives and parameters 



Primitive 


Type 


Parameters 


Comments 


SSSAR- 
UNITDATA 


Request 


SSSAR-INFO 




SSSAR-UUI 


Not used (note) 


SSSAR- 
UNITDATA 


Indication 


SSSAR-INFO 




SSSAR-UUI 


Not used (note) 


NOTE: The setting of this field is set to not used i.e. decimal value 26 according to ITU-T 
Rec. 1.366.1 [81. 



The primitives of table 3 are the standard primitives of ITU-T Rec. 1.366.1 [8]. These primitives are intended to be used 
in the lu UP. 



7.3.3 GTP-U based Transport Layer 



7.3.3.1 



General 



When the lu UP protocol layer uses the services of a GTP-U transport, it uses an established GTP-U tunnel for 
transferring frames between the GTP-U tunnel endpoints at both ends of the lu User plane access points. The RANAP 
Control Plane signalling over lu handles the signalling to establish and release the GTP-U tunnels. 

7.3.3.2 Generic Service Primitives used by the lu UP protocol 

Generic primitives are used at the GTP-U SAP. They are shown in table 4. 

Table 4: Generic primitives and parameters to and from GTP-U layer 



Primitive 


Type 


Parameters 


Comments 


lu-UP-UNITDATA 


Request 


lu-UP-payload 




lu-UP-UNITDATA 


Indication 


lu-UP-payload 





7.3.4 RTP based Transport Layer 



7.3.4.1 



General 



When the lu UP protocol layer uses the services of a RTP/UDP/IP transport, it uses an established RTP session for 
transferring frames between the two RTP endpoints at both ends of the lu User plane access points as defined in IETF 
RFC 1889 [14]. A single lu-UP PDU shall be transported as RTP payload. A dynamic Payload Type (IETF RFC 1890 
[15]) shall be used (see TS 25.414 [4]). 

7.3.4.2 Generic Service Primitives used by the lu UP protocol 

Generic primitives are used at the RTP SAP. They are shown in table 5. 
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Table 5: Generic primitives and parameters to and from RTP layer 



Primitive 


Type 


Parameters 


Comments 


lu-UP-UNITDATA 


Request 


lu-UP-payload 




lu-UP-UNITDATA 


Indication 


lu-UP-payload 





8 



Evolution of lu UP Protocol 



8.1 Principles for Protocol Evolution 



8.1.1 



Unknown field value 



The lu UP protocol may be evolved by taking into use field values that have been specified to be reserved for future use 
or have been specified as spare values. When a UP protocol entity receives an unknown field value, it can react 
differently depending whether the unknown value is reserved for future use or if it is a spare value. The following 
principles are recommended for receiver reactions: 

If a spare value is used by the sender, but not understood by the receiver, there should be a default action for the 
receiver. This default action should be defined on a field basis; 

If a value that is reserved for future use is used by the sender, but not understood by the receiver, the value 
should be rejected by the receiver. This should be done by sending a Negative Acknowledgement to the peer 
entity, if possible. Otherwise an Error Event should be generated in order to inform the upper layers and the peer 
entity; 

A received ERROR EVENT control frame shall not trigger another ERROR EVENT control frame back to the 
sender, even though e.g. the Cause value in the received ERROR EVENT control frame would not be 
understood. 

In the following the recommended actions of the receiver are handled field by field when an unknown field value is 
received. 

PDU Type 

Recommended action if reserved values used: Generate Error Event, i.e. the upper layers and the peer entity are 
informed about the error event with Cause: "PDU type unknown". 

FOG 

Recommended action if spare values used: Ignore the field and pass it onwards. 

ACK/NACK 

Proposed action if reserved values used: Generate an Error Event, i.e. the upper layers and the peer entity are informed 
about the error event with Cause: "Unknown reserved value". 

Procedure Indicator 



Recommended action if reserved values used: Generate an Error Event, i.e. the upper layers and the peer entity are 
informed about the error event with Cause: "Unknown procedure". 

Error Cause value 



Value "49" is reserved for "lu UP Mode version not supported" whatever the lu UP Mode version. 



£75/ 



3GPP TS 25.41 5 version 1 0.0.0 Release 1 53 ETSI TS 1 25 41 5 V1 0.0.0 (201 1 -04) 

Recommended action if reserved values used: Generate Error Event, i.e. the upper layers and the peer entity are 
informed about the error event with Cause: "Unknown reserved value". 

Recommended action if spare values used: Ignore the field and pass it onwards. 

8.1 .2 Adding a new field to an existing frame 

If there is a need to add a new field to an existing procedure, the following principles shall be applied: 

The PDU type defines the header mask. Therefore, a new field shall not be added to the header part of an 
existing frame and possible spare bits in the header shall not be taken into use since these would be violations of 
the header mask; 

The Procedure Indicator shall define the fields that should be in a control frame; 

There shall be only one Procedure Indicator for each procedure; 

If a new field needs to be introduced to an existing procedure (i.e. existing procedure that is defined in an 
existing UP version), the new field shall not be added to the payload part. Instead, the new field may be 
introduced by placing it to a spare field in the payload part of the frame, if possible; 

However, if a new field needs to be introduced to an existing procedure, but spare fields(s) in the payload part 
cannot be used to introduce the new field, then a new procedure shall be created and hence a new Procedure 
Indicator value shall be allocated for the new procedure; 

To enable simple protocol evolution, when a new Procedure Indicator will be introduced, the new frame shall 
include both the new fields and the fields of the old frame; 

When an implementation receives an unknown Procedure Indicator it may use the ERROR EVENT control 
frame with Cause: "Unknown procedure" to report this. This indicates to the sender that the procedure was not 
understood and it may try with an older procedure. 



8.1 .3 Adding a new PDU type 

In the future, the lu UP protocol may evolve so that there is a need to add a new PDU type. The criteria for introducing 
a new PDU type could be e.g.: 

The Procedure Indicators may run out and there is a need to have more; 

There is a need to change the header mask, e.g. the Frame Number field may need to be increased or the CRC 
field needs to be modified. 

While the PDU Type 15 is reserved for future PDU type extensions, there may be 'subtypes' under PDU Type 15 in the 
future and there also may be new procedures in these 'subtypes'. 

Thus it has to be ensured that if the same Procedure Indicator value is used under several PDU types, it should be made 
clear e.g. in the Error Event cause element, which PDU type it concerns. 

The maximum length of the Spare Extension field is defined per PDU type. Thus when a new PDU type is added, an 
appropriate length for the Spare Extension field (if any) has to be defined. For Release "99, a length of 4 octets has been 
used for data PDUs, and 32 octets for control PDUs. 

8.1 .4 Protocol version handling 

In the future, new versions of the lu UP protocol may be introduced. A reason for a new version of the protocol could 

be, e.g.: 

The earlier introduced new features or functions are required to be mandatory in the new version; 

Due to technical development, the new version of the protocol could be totally different (and incompatible) from 
the earlier version. 

The following principles shall be applied to version handling of lu UP protocol: 
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It shall be possible to introduce additional modes of operation; 

It shall be possible to evolve the operation modes independently of each other; 

There shall be independent version numbers for each mode of operation; 

The mode of operation of an lu UP protocol instance is decided by the CN. Further, the CN shall indicate those 
versions that are required to support certain features, e.g. TrFO. The version of the mode among the required 
ones shall be negotiated between the CN and UTRAN during Initialisation procedure; 

The version number of a UP operation mode may change or be unchanged between different releases; 

When the protocol is evolved it shall be made clear in the specification, which features belong to which versions; 

A new version may be an evolution (i.e. compatible) of the old version or the new version may be totally 
different from the old version. 

The structure of the PDU Type 14 header, up to and including header CRC, shall remain unchanged whatever 
the lu UP version. 
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Annex A (informative): 

Illustration of usage of RFC! for AMR speech RAB 

This annex contains information related to usage of RFCIs in the context of AMR speech RAB. 
The following figure illustrates the RFCI allocation and flow throughout the UTRAN. 
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1 . RAB Attributes: at RAB establishment or reconfiguration, the SDU format information parameter is 
passed to UTRAN. The SDU information is organised per BER i.e. RAB sub Flow. For instance, 12,2 
kbits/s AIVIR codec is passed as RAB sub flow 1 SDU size: 81 bits -class A bits-, as RAB sub flow 2 SDU 
size: 103 bits -class B bits-, as RAB sub flow 3 SDU size: 60 bits -class C-, which makes one RAB sub 
Flow Combination. This is done for all source rates (i.e. all codec modes, DTX also if included). So using 
the RAB subflows combination set from Table A.I , the SDU Formation Information Parameters for RAB 
subflow 1 is [81 ,42,39,0], for RAB subflow 2 is [1 03,53,0,0], and for RAB subflow 3 is [60,0,0,0]. The lu UP 
is used in support mode for predefined SDU size. 

2. Allocation of RFCIs: the RNC dynamically allocates an identification (RFCI) to each permitted/possible 
combinations it can offer. E.g. for kbits/s, the RNC allocates RFCI 0, for the SID, the RNC allocates RFCI 
3, for 4,75 kbits/s, the RNC allocates RFCI 2, and for 12,2. kbits/s, the RNC allocates RFCI 1 (according to 
the example table A.I). 

3. Configuration of L2/L3 based on RFCIs: RFCIs are used to configure the L2/L3. RLC is used in 
transparent mode. MAC configures its co-ordinated DCHs with the RFCIs and associates one RFCI to one 
TFI. 

4. Initialisation of lu UP: the RNC reports the permitted combinations it can offer to the transcoder using an 
inband lu INITIALISATION control frame containing the RFCIs and associated RAB sub Flow sizes. 

5. Configuration of L2/L3 based on e.g. TFIs: idem as 3. L2/L3 may use e.g. TFI to communicate with the 
Codec about the RAB sub-Flow structure of the SDU received or to be sent. 

6. RFCIS+ SDU size information: the RFCIs and associated RAB sub Flow sizes received within the lu 
INITIALISATION control frame are passed to the Codec for configuration. 

7. Example of DL frame transfer: 

7.1 . The Codec encodes a 12,2 kbits/s frame. It sends down to the lu UP an SDU with an associated 
RFCI equals to 1 (in this example). 

The lu UP packs a frame with a header containing an RFCI set to value "1 ", and the payload made 
of the SDU received from the Codec. 

The lu UP passes to L2/L3, the lu frame payload (the Codec SDU) and the RFCI. The L2/L3 uses 
this RFCI to break the lu frame onto the co-ordinated DCHs corresponding to the different bits 
protection classes. The corresponding TFI is selected. 
The radio frame is sent with the TFCI chosen by MAC. 

The L2/L3 receives the SDUs on the co-ordinated DCHs, combines them back and uses e.g. the 
TFI to indicate to the codec the structure of the received frame. 



7.2. 



7.3. 



7.4 
7.5 



Figure A.I 

For information on RAB subflow combinations used for AMR speech see TS 26.102 [12]. 
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SRNC allocates one or more possible/available RAB sub-flow combination(s) and generates RAB sub-flow 
combination set. RAB sub-flow combination number is dynamically generated by SRNC. This RAB sub-flow 
combination set is signalled towards CN with user plane signalling as described in TS 25.401 [1]. The signalling 
towards UE is to be defined by TSG-RAN WG2. 

RAB sub-flow combination set: 

A RAB sub-flow combination indicator, RFCI, indicates which RAB sub flow combination will be used for the lu user 
frames. In the communication phase the RFCI is included in the user frame, and the RFCI state the structure of the user 
frame. 

Table A.l exemplifies the allocation of 4 different RAB sub-flows combinations for 3 sub-flows and generating of RAB 
sub-flows combination set. 

Table A.l : Example of Allocation of RAB sub-flows combination indicator 





RFCI 
(RAB sub- 
Flow 
Combination 
Indicator) 


RAB sub- 
Flow 1 


RAB sub- 
flow 2 


RAB sub- 
flow 3 


Total 


Source rate 


RAB 
sub- 
flows 
combina 
tion set 


1 


81 


103 


60 


244 


Source rate 1 


2 


42 


53 





95 


Source rate 2 


3 


39 








39 


Source rate 3 

















Source rate 4 


NOTE: In the table above the greyed area shows the part that is sent in the Initialisation 
procedure in lu UP. This is what constitutes the RAB subflow combination set. 
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Annex B (informative): 

Illustration of protocol states in the lu UP 

This annex contains information related to possible protocol states for operation of the lu UP. This annex does not 
constraint implementation and is for illustration purposes only. 

The state model is common for both ends of the lu UP so that the protocol machines are operating symmetrically. This 
approach is taken to facilitate state description for all cases including possible future scenarios where the lu UP could be 
terminated elsewhere. 

NOTE: Primitive lu-UP-CONFIG-Req is used by upper layers to configure the lu UP protocol layer. It is used in 
this annex for illustrative purposes and therefore it is not defined in clause 7. 



B.1 Protocol state model for transparent mode 

Figure B.l illustrates the state model for transparent mode lu UP instances. A transparent mode instance can be in one 
of following states. 

lu-UP-CONFIG-Req 



lu-UP-UNIT-DATA-Req or 
lu-UP-UNIT-DATA-Ind or 
SSSAR-UNITDATA-Req or 
SSSAR-UNITDATA-Ind or 
lu-UP-UNITDATA-Ind or 
lu-UP-UNITDATA-Req 



lu-UP-CONFIG-Req 

Figure B.l : Protocol state model for transparent mode 



B.1.1 Null State 

In the null state the lu UP instance does not exist and therefore it is not possible to transfer any data through it. 

Upon reception of a lu-UP-CONFIG-Req from higher layer the lu UP instance is created and transparent mode data 
transfer ready state is entered. The mode information is received either through RANAP signalling or directly in the CN 
node. In the lu-UP-CONFIG-Req e.g. the following information will be indicated; 

Transparent mode. 

B.1 .2 Transparent Mode Data Transfer Ready State 

In the transparent mode data transfer ready state, transparent mode data can be exchanged between the entities. 

Upon reception of lu-UP-CONFIG-Req indicating release from higher layer, the lu UP instance is terminated and the 
null state is entered. 
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B.2 Protocol state model for support mode for predefined 
SDU sizes 

Figure B.2 illustrates the state model for support mode lu UP instances. A support mode instance can be in one of the 
following states. 

lu PDU ► 

Primitive between layers ► 



lu-UP-CONFIGRSq^ Ir'iti''lis^ti°iLTnitialisation 

WRepeat) 



Last Initialisation 

CK sent or 
Last Initialisation 
Ack received 




lu-UP-CONFIGReq 



lu-UP-STATUSIndV 
(Rate control) 



lu-UP-DATAReqor 

lu-UP-DATAIndor 

SSS AR-UNITDATAReq or 

SSS AR-UNITDATAkid or 

lu-UP-UNITD ATAtnd or 

lu-UP-UNITDATAReq 



Rate controP 
PDU 



Figure B.2: Protocol state model for support mode 

B.2.1 Null State 

In the null state the lu UP instance does not exist and therefore it is not possible to transfer any data through it. 

Upon reception of a lu-UP-CONFIG-Req from higher layer the lu UP instance is created and initialisation state is 
entered. In the lu-UP-CONFIG-Req e.g. the following information could be indicated: 

Support mode for predefined SDU sizes; 

Time alignment (FFS); 

Indication of delivery of erroneous SDUs; 

Periodicity; 

required UP versions. 

B.2.2 Initialisation State 

In the initialisation state the instance exchanges initialisation information with its peer lu UP instance. 

Upon reception of lu-UP-CONFIG-Req indicating release from higher layer, the lu UP instance is terminated and the 
null state is entered. 
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Upon sending or receiving of an INITIALISATION control frame the lu UP instance remains in the Initialisation state. 
The sending side starts a supervision timer Tinij. The receiving side acknowledges the INITIALISATION control frame 
with a positive acknowledgement or a negative acknowledgement. 

Upon reception of the last initialisation acknowledgement frame, the supervision timer Tinit is stopped and the lu UP 
instance enters SMpSDU data transfer ready state. 

After sending a positive acknowledgement of the last INITIALISATION control frame, the lu UP instance enters 
SMpSDU data transfer ready state. Note that CN does not know if the initialisation ACK was correctly received by the 
RNC (and Initialisation procedure successfully completed) until it receives RAB assignment response, or use data from 
the RNC. The CN must therefore be able to continue receiving INITIALISATION control frames by re-entering the 
Initialisation state (from Support Mode Data Transfer Ready State), if the CN has started to send user data before 
receiving the indication that Initialisation was successfully completed. 

Upon reception of an INITIALISATION NEGATIVE ACKNOWLEDGEMENT control frame (INIT NACK) 
initialisation frame can be repeated n times. 

If after n repetitions, the Initialisation procedure is unsuccessfully terminated (due to n negative acknowledgements or 
timer expires) the Handling of Error Event procedure is used to report the Initialisation failure and the lu UP instance 
remains in the initialisation state. Upon reception of an INITIALISATION control frame the Initialisation state is 
entered. 

B.2.3 Support Mode Data Transfer Ready State 

In the support mode data transfer ready state, support mode data can be exchanged between the peer lu UP instances. 

Upon reception of lu-UP-DATA-Request from the upper layer or SSS AR-UNITDATA-Indication or 
lu-UP-UNITDATA-Indication from TNL layer, appropriate user data transfer procedures are performed. lu UP instance 
remains in the SMpSDU data transfer ready state. 

Upon sending of lu-UP-DATA- Indication or SSS AR-UNITDATA-Request or lu-UP-UNITDATA-Request the lu UP 
instance remains in the SMpSDU data transfer ready state. 

Upon sending or receiving of a rate control PDU the lu UP instance remains in the SMpSDU data transfer ready state. 

Upon sending of a lu-UP-STATUS-Indication (rate control) the lu UP instance remains in the SMpSDU data transfer 
ready state. 

Upon reception of lu-UP-CONFIG-Req from higher layer the lu UP instance is terminated and the null state is entered. 

Upon detection of a protocol fault, lu-UP-STATUS-Indication is sent to upper layer an ERROR EVENT control frame 
may be sent over lu UP. 

In case of handover or relocation. Initialisation procedures may have to be performed and lu UP instance may have to 
enter the initialisation state. 
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Annex C (informative): 
Open Issues of the lu UP 

This annex contains information related to open issues left in the lu UP protocol. 
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Annex D (informative): 

Distributed rate decision within RNC 

This annex contains information related to the distributed rate decision within an RNC (see also within TS 23.153 [13]) 

The lu Rate Control procedure over lu UP is normally controlled by the entity controlling the rate control over UTRAN 
i.e. the SRNC. The SRNC may send RATE CONTROL control frames in uphnk (to the CN) to control the rates in 
downlink. The SRNC may also send RATE CONTROL control frames in downlink (to the UE) to control the rates in 
uplink. The lu Rate Control procedures for both directions are independent of each other, i.e. different rates may be 
permitted in uplink and downlink, see figure D.l. 



UE 



SRNC 



Rate Control for uplink 



User Data with uplink Rates 



User Data 



CN 



User Data 



Rate Control for downlink 



User Data with downlink Rates 



Figure D.l : Rate Control for uplink and downlink 

The rates associated with the service could be rank ordered from "lower" to "higher" according to their SDU bit rates 
and RFCI values, with RFCI=0 having the lowest rate. A rate lower than the currently allowed maximum rate shall not 
be forbidden while a higher rate is forbidden. In order to stabilise the lu Rate Control procedure and its influences on 
the radio link and the network, typically only one additional rate shall be forbidden or permitted in subsequent RATE 
CONTROL control frames. 

In some cases, as TrFO and TFO, the rate is also controlled by the remote partner at the other end of the lu UP. The 
SRNC may then also receive RATE CONTROL control frames in downlink (from the CN) controlling the rates in 
uplink. Only rates that are permitted by both sides for one direction shall be used in that direction. The SRNC shall 
therefore combine these RATE CONTROL control frames from the CN with its own control frames for the uplink 
direction by taking the RATE CONTROL control frame with the lowest maximum rate and shall send this RATE 
CONTROL control frame downlink to the UE. This combination is denoted in figure D.2 with "Rate Control (CN ® 
RNC)". 
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Figure D.2: Distributed Rate Control for uplink and downlink 
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